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I.  INTRODUCTION 


Given  the  high  number  of  disasters  over  the  past  decade  both  at  home  and  abroad, 
a  great  deal  of  attention  has  been  given  to  the  study  of  Disaster  Relief/Humanitarian 
Assistance  (DR/HA),  likely  due  to  heightened  levels  of  global  awareness  made  possible 
through  advances  in  communication  technology. 

Within  the  first  24  hours  following  a  disaster,  a  myriad  of  activities  must  occur, 
activities  such  as  search  and  rescue  operations,  triage  and  emergency  medical  sendees, 
and  the  maintenance  of  civil  order  and  public  safety.  One  common  thread  among  all  of 
these  activities  is  that  they  are  time  sensitive  and  require  timely  information  to  support  a 
great  deal  of  coordination  across  multiple  agencies. 

The  specific  problem  addressed  in  this  project,  which  was  prevalent  during 
Hurricane  Katrina,  is  the  lack  of  surveillance  and  damage  assessment  systems  that  can  be 
quickly  deployed  and  efficiently  employed,  functioning  independently  from  any  existing 
systems,  and  providing  reliable  communications  for  information  gathering  and 
coordination  during  this  critical  period.  This  type  of  system  could  provide  emergency 
and  relief  agencies  a  common  operational  picture,  exponentially  increasing  their 
situational  awareness  and,  in  turn,  making  it  possible  to  provide  more  efficient  support  to 
the  victims.  Without  this  new  found  awareness,  relief  agencies  will  not  know  where  to 
respond,  what  personnel,  equipment  and  supplies  are  needed,  or  what  needs  to  be 
procured.  Though  most  governments,  local  or  national,  do  have  departments  established 
to  handle  such  crises,  most  do  not  have  a  “plan  B”  in  the  event  the  existing 
communications  infrastructure  is  destroyed.  For  underdeveloped  countries  such  as  Sri 
Lanka,  Cambodia,  Pakistan,  Indonesia,  and  Thailand,  who  lack  a  robust  infrastructure 
and  readily  available  resources,  a  system  such  as  this  could  potentially  save  thousands  of 
lives  that  may  have  otherwise  been  lost. 

In  May  2008,  the  Cooperative  Operations  and  Applied  Science  and  Technologies 
Studies  (COASTS)  team  conducted  a  live  experiment  using  a  data  collection  system 
aimed  at  filling  the  previously  mentioned  “awareness  gap”  following  a  disaster.  The 
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system  was  comprised  of  numerous  commercial  off-the-shelf  (COTS)  technologies  which 
were  fielded  and  operated  by  Naval  Postgraduate  School  (NPS)  students  with  the  aid  of 
technology  representatives.  The  COASTS  experiment  was  used  to  test  and  demonstrate 
the  capabilities  and  value  of  an  independent  damage  assessment  system,  consisting  of 
multiple  individual  technologies,  being  employed  following  a  tsunami  with  an  end  goal 
of  sending  a  comprehensive  damage  report  from  the  Joint  Operations  Command  Center 
(JOCC)  to  all  the  agencies  that  require  it. 

The  May  experiment  was  based  on  a  post  tsunami  scenario  script  developed  by 
the  COASTS  team.  The  experiment  was  preceded  by  numerous  test  runs  the  week  prior 
to  ensure  the  conditions  were  set  for  a  successful  test.  During  these  practice  runs,  it 
became  very  apparent  that  the  system  had  to  be  employed  in  favorable  conditions  and 
factors  such  as  high  winds,  heavy  rain,  or  random  equipment  failures  such  as  power 
outages  significantly  degraded  the  data  collection  systems  performance.  Despite  the 
setbacks  during  the  test  runs,  COASTS  was  able  to  conduct  a  successful  live  simulation 
and  determined  that  the  data  collection  system  was  effective  and  capable  of  completing 
the  mission. 

Live  simulation  experiments  are  inherently  limited,  since  they  can  only  be  carried 
out  a  small  number  of  times.  The  COASTS  experiment  was  no  exception  as  the  full 
simulation  was  only  run  once.  Therefore,  random  factors  such  as  weather,  climate, 
geography  and  random  failures  of  personnel  and  equipment  were  only  represented  by  a 
single  data  point  in  the  one  simulation  run.  This  makes  it  impossible  to  understand  the 
effects  of  these  factors  on  the  performance  of  the  system.  It  is  for  this  very  reason  that 
discrete-event  simulation  (DES)  modeling  is  such  an  excellent  resource. 

The  value  of  using  DES  modeling  lies  in  the  fact  that  the  parameters  and  inputs  of 
the  system  being  tested  can  be  altered  over  multiple  simulation  runs.  By  altering  these,  it 
allows  for  that  system  to  then  be  tested  under  a  whole  host  of  situations,  in  turn  giving  the 
researcher  an  ideal  of  how  the  system  might  perform  given  those  conditions. 
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The  primary  goal  of  this  project  is  to  expand  on  the  COASTS  experiment  and 
explain  how  the  data  collection  system  would  operate  under  more  realistic  conditions. 
This  is  done  by  first  building  a  model  based  on  the  COASTS  script  using  discrete  event 
simulation  modeling  software  and  information  obtained  from  the  COASTS  experiment. 
Using  the  Script  Model  as  a  template,  a  Baseline  Model  is  then  created  by  changing  the 
activity  times  that  were  constant  in  the  Script  Model  to  activity  times  drawn  randomly 
from  a  probability  distribution  to  reflect  more  realism  and  variability.  The  Baseline 
Model  is  then  enhanced  to  reflect  possible  equipment  failures  as  well  as  delays  due  to 
inclement  weather.  The  results  of  these  models  are  summarized  and  analyzed  and 
recommendations  are  made. 

Looking  ahead.  Chapter  II  provides  a  background  of  COASTS  to  include 
additional  information  on  the  problem,  a  description  of  the  live  experiment,  and 
characteristics  of  system  equipment.  Chapter  III  describes  the  simulation  model  and  how 
it  was  built,  states  the  model  assumptions,  and  illustrates  the  creation  of  the  Script  and 
Baseline  Models.  Chapter  IV  explains  how  the  experimental  models  were  created  and  is 
the  precursor  to  Chapter  V  which  provides  results  and  analysis  of  the  experimental 
models.  Finally  Chapter  VI  summarizes  the  project,  conclusions  and  recommendations. 
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II.  RESEARCH  BACKGROUND 


This  chapter  provides  the  background  information  about  the  COASTS 
organization.  The  chapter  then  touches  on  the  description  and  setting  for  the  COASTS 
live  experiment,  to  include  a  brief  description  of  the  data  collection  system  and 
equipment  tested.  The  chapter  wraps  up  with  a  short  summary  of  the  tsunami  script 
followed  by  the  COASTS  experiment  results. 

A.  THE  COASTS  ORGANIZATION 

COASTS  is  a  research  based,  NPS  affiliated,  student  run  organization.  Founded 
in  2004  by  NPS  Research  Professors  Brian  Steckler  and  James  Ehlert,  COASTS 

organizes  and  executes  live  experiments  to  demonstrate  the  capabilities  of 
low  cost,  state-of-the-art,  unclassified  networked  air,  ground,  and  maritime 
equipment  for  the  purposes  of  providing  real  time  information  to  tactical 
and  remote  decision  makers.  The  COASTS  team  emphasizes  the  use  of 
COTS  technologies  using  tailored  scenarios  to  test  and  evaluate  areas  of 
research  that  are  critical  to  both  U.S.  and  international  security  objectives. 

In  FY2008,  the  COASTS  objectives  encompassed  field  experimentation 
and  technology  demonstrations  in  the  U.S.,  Thailand,  Malaysia, 
Singapore,  and  Indonesia.1 

B.  DESCRIPTION  OF  LIVE  EXPERIMENT 

The  location  chosen  by  COASTS  to  conduct  the  live  experiment  in  May  of  2008, 
also  known  as  field  experiment  V  (FEXV),  was  Prachuap  Khiri  Khan,  Thailand,  on  a 
Royal  Thai  Air  Force  (RTAF)  base  which  is  home  to  Wing  5  (Figure  1).  The  base  is 
located  in  Ao  Manao  Bay  which  is  southeast  of  Prachuap  Khiri  Khan,  on  the  Gulf  of 
Thailand  (Figures  1&2).  Wing  5  includes  an  RTAF  AU-23  Monoplane  squadron  and 
hosted  the  experiment.  Wing  5  conducted  numerous  coordination  meetings  with 
COASTS  and  provided  a  large  portion  of  the  requisite  personnel  and  equipment  support 
for  the  experiment.  From  the  COASTS  side,  approximately  80  personnel,  including  the 


1  Taken  from  COASTS  2008  Mission  Power  Point  Brief  dated  3  October  2007. 
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author,  attended  the  May  experiment  ranging  from  NPS  students  and  faculty.  Department 
of  Defense  personnel,  civilian  contractors,  and  representatives  from  the  Office  of  the 
Secretary  of  Defense. 
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Figure  1 .  Map  of  Thailand  Showing  Prachuap  Khir  Khan,  the  Experiment  Site  on 

the  Gulf  Coast  (From:  Internet,  Google  Images) 
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Figure  2.  Map  of  Ao  Manao  Bay,  Wing  5  Showing  the  RTAF  Base  and  Airstrip 

(From:  Google  Earth) 


1.  Equipment  Tested  During  COASTS  Experiment 

During  the  live  experiment,  there  were  five  main  data  collection  and  transmission 
platforms  that  comprised  the  system  being  tested.  These  were:  (1)  the  RTAF’s  AU-23 
Peacemaker  Monoplane;  (2)  the  AeorVironment  Raven  RQ-llb  Mini  Unmanned  Aerial 
Vehicle  (MUAV);  (3)  the  Royal  Thai  Navy’s  (RTN)  Pattani-Class  Patrol  Craft,  Fast 
(PCF);  (4)  the  JOCC;  and  (5)  a  Mobile  Emergency  Command  Post  (MECP)  that  utilized 
an  experimental  cell  phone  technology  developed  at  NPS  known  as  Twiddlenet.  The 
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following  subsections  provide  a  brief  description  of  each  technology  as  well  as  its 
purpose  during  the  COASTS  experiment  and  Figure  3  provides  a  more  detailed  view  of 
the  experiment  area  to  include  how  various  equipment  was  connected  to  the  JOCC. 


MECP  localized 
cell  and  WiFi  Cloud 


MECP  connected  to 


JOCC  via 

Microwave  Link  and 
BGAN  TwiddleNet 


RTAF  AU-23 
connected  via 
PMR  Microwave 


Cyberbug,  Raven, 
and  WASP  UAV's 
connected  via 
dedicated  links 


ICX  Radar  Coverage 


Patrol  Craft 
Connected  via 
RuckusDZ  to 
Vivato  Cloud 


Onjf IfWsr 


Underwater  ALAN  Camera 


Figure  3.  Aerial  View  Showing  How  AU-23,  PCF,  MUAV,  and  MECP  were 
Communicating  with  the  JOCC  (From:  COASTS  Network  P-Point) 


a.  Royal  Thai  Air  Force ’s  A  U-23  Monoplane  (Peacemaker) 

The  AU-23  Peacemaker  is  essentially  a  modified  version  of  the  Swiss 
Pilatus  PC-6  Porter  civilian  utility  aircraft.  First  introduced  in  the  late  1950s,  the 
currently  used  turboprop  version  was  introduced  in  1961  and  then  upgraded  in  1963  to  its 
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current  engine  configuration.  Within  the  United  States,  the  AU-23  was  produced  by 
Fairchild  Industries  who  in  turn  sold  35  of  the  aircraft  to  the  Royal  Thai  Air  Force 
following  Vietnam. 

The  AU-23  is  famous  for  its  short  take-off-and-landing  (STOL)  capability 
requiring  little  more  that  a  soccer  field  to  do  both.  Operated  by  a  single  pilot,  the  AU-23 
and  can  hold  up  to  10  passengers,  has  a  maximum  speed  of  153  mph,  a  maximum  range 
of  870  nautical  miles  and  a  maximum  operating  altitude  of  25,000  ft.  Since  the  RTAF 
variant  is  armed,  it  is  used  primarily  for  counter-insurgency  operations  making  it  a 
perfect  fit  for  surveillance. 

During  the  live  experiment,  the  AU-23  was  equipped  with  very  high 
frequency  (VHF)  communications  as  well  as  a  video  capability.  It  was  launched 
immediately  for  the  purpose  of  providing  the  JOCC  initial  reports  of  the  disaster  area  to 
include  route  information  that  could  be  used  to  direct  the  MECP. 

b.  Raven  RQ-llb  Mini  Unmanned  Aerial  Vehicle 

The  Raven  RQ-llb  or  Raven  B  is  a  MUAV  manufactured  by 
AeroVironment,  Inc.  Its  purpose  is  low  altitude  surveillance  and  reconnaissance  and  is 
used  by  militaries  throughout  the  world.  Due  to  the  system’s  mobility  and  rapid 
deployment  capability,  is  currently  regarded  as  the  “most  prolific  unmanned  aerial 
vehicle  system  in  the  world  today.”2 

The  Raven  B  is  a  hand  launched  MUAV  that  can  be  guided  by  a  ground 
station  or  fly  autonomously  using  advanced  global  positioning  system  (GPS)  navigation. 
It  power  plant  is  a  battery  powered  electric  motor  giving  it  a  limited  endurance  of  60  to 
1 10  minutes  depending  on  battery  type. 


2  Wikipedia,  http://enAvikipedia.oru/wiki/RO-l  1  Raven 
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The  Raven  B  has  a  line-of-site  (LOS)  range  up  to  10  kilometers,  speed 
from  32-81  km/h,  and  a  maximum  operating  altitude  of  approximately 
500ft  above  mean  ground  level  (MGL)  or  14,000ft  above  mean  sea  level 
(MSL).  The  Raven  can  deliver  real  time  color  or  infrared  imagery  to  the 
ground  control  and  remote  viewing  stations.3 

During  the  live  experiment,  the  Raven  B  was  launched  from  the  JOCC  site 
only  after  the  MECP  had  reached  its  destination.  Once  over  the  disaster  area,  the  MUAV 
was  used  to  survey  the  damage  and  provide  real  time  color  video  back  to  the  control 
station  located  close  to  the  JOCC  which  was  then  routed  via  a  wireless  link  to  the  JOCC. 

c.  Royal  Thai  Navy's  Patrol  Craft ,  Fast 

Powered  by  a  diesel  chassis  and  large  enough  to  house  a  small  crew,  the 
PCF  packs  enough  punch  to  not  only  patrol  the  calm  riverine  and  coastal  water  but  to  also 
endure  the  choppy  seas  when  required.  The  PCF’s  relatively  small  size  makes  it  a  perfect 
fit  for  such  missions  as  anti-smuggling,  anti-trafficking,  fishery  enforcement,  and  anti¬ 
piracy. 

During  the  live  experiment,  the  PCF  was  dispatched  to  the  disaster  area  in 
order  to  augment  the  aerial  assessment  provided  by  the  AU-23  and  to  provide  a  coastal 
perspective  of  the  damage.  Its  primary  mission  was  to  transmit  a  voice  report  back  to  the 
JOCC  via  VHF  communications  and  then  loiter  in  the  area  providing  aid  where  needed. 

d.  Joint  Operations  Command  Center 

The  JOCC  was  located  on  base  in  a  pre-existing  building  located  out  of 
the  disaster  area  but  close  enough  to  it  that  the  aerial  platforms  could  perform  their 
mission.  The  JOCC  was  the  central  coordination  point  for  the  MUAV  operator,  MECP 
Team,  and  additional  support  personnel  prior  to,  and  during,  the  COASTS  experiment. 
The  JOCC  was  set-up  so  that  all  could  obtain  and  maintain  a  common  operational  picture 
of  what  was  occurring.  It  was  the  nerve  center  of  the  experiment  and  was  home  to  all  key 


3  AeroVironment  website,  http://www.avinc.com/uas  product  details.asp?Prodid=  1 
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crisis  team  personnel.  All  functions  of  the  experiment  were  controlled  from  the  JOCC  to 
include  the  commands  for  launch  and  recovery  of  aerial  and  ground  platforms,  audio  and 
video  reception/transmission,  and  report  generation/dissemination. 

e.  Mobile  Emergency  Command  Post  and  Twiddlenet 

As  previously  mentioned,  the  MECP  represented  any  ground  platform  that 
has  the  ability  to  safely  transport  a  specified  amount  of  personnel,  supplies,  and  data 
collection  equipment  into  the  disaster  area  for  purposes  of  damage  assessment.  For  the 
purposes  of  this  experiment,  the  MECP  platform  was  a  10-passenger  van.  The  MECP 
also  performed  emergency  medical  services  once  in  place  but  this  is  a  secondary  mission 
to  the  primary  of  data  collection. 

The  key  technology  of  the  MECP  is  the  NPS-developed  Twiddlenet.  The 
attraction  to  Twiddlenet  is  that  it  can  tie  cell  phones  and  personal  digital  assistants  (PDA) 
into  a  hastily  formed  network  (HFN)  created  by  the  crisis  team.  This  capability  is 
extremely  beneficial  and  has  enormous  applicability  when  the  disaster  area  has  lost 
commercial  cell  phone  communications.  During  the  live  experiment,  the  Twiddlenet 
operating  within  the  MECP  performed  the  mission  of  providing  video  and  data 
transmissions  back  to  the  JOCC. 

2.  Brief  Summary  of  Live  Experiment  Scenario  Script 

The  post  tsunami  scenario  script  developed  and  executed  by  COASTS  can  be  seen 
in  its  entirety  in  Appendix  A.  The  following  is  a  brief  summary  of  the  script  and  what 
occurred.  (During  the  live  experiment,  what  was  supposed  to  happen  according  to  the 
script  and  what  did  happen  were  close  enough  for  the  purposes  of  this  project  that  it  can 
be  summed  up  as  “what  occurred.”) 

Approximately  one  hour  after  a  tsunami  hits  the  coastline,  the  crisis  team, 
consisting  of  all  scenario  participants  and  equipment,  is  assumed  to  have  already  arrived 
near  the  disaster  site  and  requests  permission  from  local  authorities  to  survey  the  affected 
area.  Once  permission  to  survey  the  disaster  area  is  given,  the  simulation  clock  begins. 
Approximately  one  hour  of  coordination  and  preparation  takes  place  and  it  is  at  the 
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conclusion  of  this  hour  that  the  equipment  is  ready  to  be  employed.  The  Hastily  Formed 
Network  (HFN)  used  to  tie  all  crisis  team  equipment  together  is  also  established  as  part 
of  the  JOCC  preparation  during  the  one-hour  coordination  and  equipment  preparation 
window  allowing  the  system  to  operate  independent  of  local  communications 
infrastructure.  The  timeline  below  represents  simulation  time,  not  real  clock  time  during 
the  live  simulation: 

•  0:00  to  +1:01  the  equipment  is  prepped,  coordination  takes  place,  and  the 
HFN  is  established 

•  +1:02  the  AU-23  Monoplane  takes  off  for  purposes  of  surveying  the 
disaster  area 

•  +1 :03  the  MECP  departs  the  base  enroute  to  the  affected  area  for  purposes 
of  damage  assessment  and  triage 

•  +1:15  the  AU-23  arrives  over  disaster  area  and  starts  streaming  video 
back  to  JOCC  via  very  high  frequency  (VHF)  communications 

•  +1:15  the  RTN  patrol  boat  arrives  in  the  disaster  area  and  provides  a 
damage  assessment  using  Voice  Over  Internet  Protocol  (VOIP),  remains 
in  area  until  end  of  scenario 

(Timeline  Compression)  60  minutes  simulated  elapsed.  At  this  point  in  the 
script,  there  is  a  60-minute  timeline  compression  thereby  adding  one  hour  to  the 
simulation  timeline.  During  this  simulated  hour,  routes  are  determined  into  the  disaster 
area  for  disaster  relief  teams.  The  JOCC  relays  this  information  to  the  MECP  Team  who 
was  already  on  the  move  to  the  disaster  area  and  the  AU-23  uses  loiter  capability  to 
remain  over  the  disaster  area  and  provide  continued  support  until  end  of  scenario. 

•  +2:20  MECP  arrives  at  disaster  site  and  begins  setting  up  links,  MUAV 
launched  from  base  to  support  MECP 

•  +2:40  MECP  setup  complete,  data  transfer  with  JOCC  ongoing  via 
satellite  communications  (SATCOM),  MUAV  providing  JOCC  with  video 
feed  of  disaster  area 
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•  +2:45  JOCC  sends  disaster  reports  to  host-nation  command  center  and 

local  non-governmental  organization  (NGO)  headquarters 

3.  Brief  Summary  of  Live  Experiment  Results4 

a.  Pre-Experiment  Test  Runs 

The  final  COASTS  experiment  was  preceded  by  a  handful  of  practice 
experiments,  or  test  runs.  There  were  a  number  of  hang-ups  just  prior  to  and  during 
these  practice  experiments  such  as  a  power  outage  at  the  JOCC.  Since  the  JOCC  is  the 
hub  for  all  communications  as  well  as  the  centerpiece  for  the  HFN,  losing  power  became 
a  critical  situation.  Every  activity  in  the  system  was  eventually  affected  by  the  power 
outage  and  having  a  backup  power  source  became  a  key  learning  point.  In  addition  to  the 
JOCC  power  outage,  a  severe  rainstorm  popped  up  during  one  of  the  test  runs  bringing 
with  it  high  winds,  heavy  rain,  and  lightning.  The  storm  wreaked  havoc  on  the  system  as 
a  whole  resulting  in  the  grounding  of  all  aircraft  and  damages  to  the  MUAV  and  HFN 
infrastructure.  These  particular  occurrences  in  addition  to  a  few  more  potential  issues  are 
used  in  experimental  scenario  development  contained  in  Chapter  IV. 

b.  Live  Experiment 

During  the  full  live  experiment  run  the  HFN  proved  to  be  reliable  and 
favorable  weather  conditions  allowed  the  AU-23  and  MUAV  to  get  in  the  air,  loiter  over 
the  disaster  area,  and  transmit  data  back  to  the  JOCC  for  use  elsewhere  in  the  scenario. 
The  MECP  kept  to  the  timeline  and  was  able  to  accomplish  all  tasks  including  image 
transmission  and  the  delivery  of  emergency  medical  services  to  the  victims  within  its 
immediate  area.  By  all  accounts  the  live  experiment  was  a  success  and  the  data 
collection  system  proved  to  be  capable  of  operating  under  favorable  conditions. 


4  Summary  taken  from  FEX  V  Daily  Sitrep  (Final)  from  Tuesday,  May  27,  2008  (Appendix  B) 
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III.  SCRIPT  AND  BASELINE  MODEL 


Chapter  III  begins  with  assumptions  and  key  metrics  for  all  models  developed  as 
part  of  this  project.  Next,  the  construction  of  the  Script  and  Baseline  Models  is  described 
to  include  details  about  the  commonalities  of  the  models  such  as  flow,  activities,  and 
outlines  what  is  contained  in  each.  Finally,  the  Script  and  Baseline  models  are  compared 
using  the  metrics  defined  below. 

A.  ASSUMPTIONS 

The  overarching  objective  of  this  project  is  to  expand  on  the  live  experiment  in 
order  to  test  the  performance  of  the  entire  system  under  a  variety  of  circumstances,  not  to 
test  the  individual  equipment,  technologies,  and  preparation  that  made  it  possible. 
Therefore,  assumptions  are  necessary.  The  first  two  models  constructed  for  this  project 
were  the  Script  Model  that  contains  no  variability  but  matches  the  live  simulation  script 
and  a  Baseline  Model  where  probability  distributions  were  inserted  for  timed  activities  to 
reflect  real  world  variability.  The  Baseline  Model  also  serves  as  the  model  from  which 
the  experimental  models  were  created.  The  following  is  a  list  of  assumptions  which  apply 
to  all  models: 

•  The  disaster  area  is  within  range  of  all  equipment 

•  The  weather  conditions  ultimately  permit  the  systems  employment, 
although  may  cause  delays 

•  All  equipment  and  personnel  are  ultimately  functional  although  may 
experience  recoverable  failures 

B.  METRICS 

In  keeping  with  the  main  purpose  of  this  project,  which  is  to  expand  on  the 
COASTS  experiment  and  explain  how  the  data  collection  system  would  operate  under 
more  realistic  conditions,  a  metric  of  total  time  to  mission  completion  is  used  to  evaluate 
and  compare  all  models.  For  the  purposes  of  this  project,  total  time  means  the  time  it 
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takes  for  the  JOCC  to  generate  and  transmit  a  comprehensive  damage  assessment  to  the 
non-governmental  organizations  (NGOs)  supporting  the  DR/HA  effort.  This  step  is  what 
all  other  activities  in  the  system  are  working  towards,  the  step  that  will  take  all  compiled 
data  and  turn  it  into  usable  information.  Until  this  happens,  it  is  assumed  that  the  only 
persons  who  know  the  full  extent  of  the  damage  are  the  victims  and  the  HA/DR 
personnel  on  site  working  to  produce  the  assessment. 

That  said,  there  are  additional  metrics  that  can  be  useful,  such  as  the  time  it  takes 
for  each  entity  to  survey  the  disaster  area  and  transmit  a  damage  assessment  to  the  JOCC. 
These  metrics  can  be  extremely  helpful  when  examining  the  effects  of  temporary  failures 
and  weather  delays  in  the  enhanced  models,  further  demonstrating  how  problems  with 
one  entity  can  significantly  delay  all  others. 

C.  SCRIPT  MODEL 

The  Script  Model  was  built  according  to  the  COASTS  script  with  all  times 
constant.  The  model  times  are  simulation  times  as  opposed  to  real  times  and  are  based  on 
an  interpretation  of  the  script  which  lasts  1 65  minutes.  What  was  not  built  into  the  Script 
Model  was  the  time  it  takes  for  the  crisis  team  to  travel  to  the  disaster  area,  link  up  with 
the  host  nation  (HN)  government,  and  gain  permission  to  setup  and  employ  the  system. 
This  cannot  be  projected  due  to  the  global  nature  of  disasters,  various  modes  of  travel, 
requirements  of  and  relationships  with  different  governments,  and  a  whole  host  of  other 
variables  beyond  the  control  of  all  involved. 

1.  Script  Model  Flow 

The  simulation  model  was  developed  by  first  creating  a  precedence  diagram  for 
all  the  activities  involved  in  the  mission.  As  described  later,  the  Script  and  Baseline 
Models  have  exactly  the  same  flow.  The  only  difference  between  them  is  the  activity 
times  which  are  constant  in  the  Script  Model  and  probabilistically  distributed  in  the 
Baseline  Model.  Subsequent  paragraphs  will  provide  a  description  of  the  model  flow  as 
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well  as  flowchart  snapshots  (Figures  4&5).  The  following  precedence  table  (Table  1) 
was  compiled  to  construct  the  model  flow  and  the  activity  letters  in  the  table  correspond 
to  the  activity  letters  in  the  flowchart  figures. 


ACTIVITY  PRECENDENCE  TABLE 

ACTIVITY  DEFINED 

ACTIVITY 

PRECEEDS 

PREP  AU-23 

A 

F 

PREP  JOCC 

B 

C 

PREP  PCF 

C 

G 

PREP  MECP 

D 

H 

PREP  MUAV 

E 

I 

AU-23  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

F 

J 

PCF  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

G 

K 

LAUNCH  MECP  AND  BEGIN  TRANSIT  TO  DISASTER 

AREA 

H 

M 

MUAV  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

I 

0 

AU-23  SURVEYS  DISASTER  AREA  AND  SENDS  DATA 

TO  JOCC 

J 

L 

PCF  SURVEYS  DISASTER  AREA  AND  SENDS  DATA  TO 

JOCC 

K 

L 

JOCC  PROCESSES  DATA  FROM  AU-23  AND  PCF,  SENDS 
ROUTE  DATA  TO  MECP 

L 

M 

MECP  RECEIVES  ROUTE  DATA  FROM  JOCC 

M 

N 

MECP  TRANSITS  TO  DISASTER  AREA 

N 

1.0 

MECP  SETS  UP,  SURVEYS,  AND  SENDS  DATA  TO  JOCC 

0 

0 

MUAV  SURVEYS  DISASTER  AREA  AND  SENDS  DATA 

TO  JOCC 

P 

Q 

JOCC  PROCESSES  DATA  FROM  MECP  AND  MUAV, 
SENDS  DAMAGE  ASSESSMENT  TO  NGO’S 

Q 

END 

Table  1 .  Activity  precedence  table  for  use  with  model  flowchart  (Figures  4  &  5) 


The  activity  flow  in  the  model  commences  with  the  Tsunami  strike  which  leads  to 
the  crisis  team  link-up  with  local  government  officials  (both  civil  and  military).  Once  the 
link-up  takes  place  and  authorization  is  given  to  the  COASTS  team  to  survey  the  disaster 
area,  a  preparation  phase  starts  that  includes  the  crisis  team  establishing  the  HFN  and 
prepping  all  equipment.  The  AU-23  is  launched  first  for  the  purpose  of  providing  initial 
damage  assessments  and  to  report  back  with  usable  route  information  that  can  be  passed 
from  the  JOCC  to  the  MECP.  As  the  AU-23  launched,  the  MECP  is  dispatched  to  the 
disaster  area  with  the  intention  of  receiving  route  updates  on  the  move  in  order  to  find  its 
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intended  destination.  Also  at  the  same  time,  the  PCF  is  directed  to  proceed  from  a  nearby 
port  to  the  shoreline  of  the  disaster  area  in  order  to  provide  reports  based  on  the  coastline 
perspective.  After  a  short  transit  time,  the  AU-23  arrives  at  the  disaster  area  and  begins 
transmitting  video  and  damage  assessments  back  the  JOCC.  Similarly,  after  some  transit 
time,  the  PCF  arrives  at  the  disaster  area  and  communicates  damage  assessment 
information  to  JOCC.  The  JOCC  uses  all  this  information  to  generate  route  information 
that  can  be  passed  along  to  the  MECP  (Figure  4). 


AU-23  LAUNCH  AND  AU-23  SURVEYS  DISASTER 
TRANS  IT  TO  DISASTER  AREA  AND  SENDS  DATA  TO 

PREP  AU-23  AREA  JOCC 


Figure  4.  Flowchart  Snapshot  Showing  Tsunami  Strike,  Preparation  Processes,  and 

Data  Transmissions  To  and  From  JOCC 


Upon  the  MECP's  arrival  at  its  final  destination,  the  signal  is  given  for  the 
MUAV  to  launch.  The  MECP  then  proceeds  to  set  up  and  the  MUAV  is  directed  over 
the  disaster  area  by  the  JOCC  in  order  to  survey  the  affected  area  and  transmit  assessment 
data  back  to  the  JOCC.  The  MECP  is  now  set  up,  the  MUAV  is  over  the  disaster  area. 
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and  both  are  transmitting  video  and  data  back  to  the  JOCC.  The  JOCC  uses  information 
from  the  AU-23,  PCF,  MUAV,  and  the  MECP  to  complete  the  final  system  step  of 
transmitting  the  summarized  damage  assessment  report  to  the  NGO’s  (Figure  5). 


JOCC  PROCESSES  DATA 
FROM  MECP  AND  UAV. 
SENDS  REPORT  TO  NGO'S 


DISASTER  AREA 


Figure  5.  Flowchart  Snapshot  Showing  JOCC’s  Transmission  to  NGO’s 


2.  Script  Model  Creation 

The  Script  Model  was  created  with  processes  for  the  activities  defined  above  and 
flows  that  follow  the  description  given  above.  Details  about  the  entities  and  the  processes 
within  the  Script  Model  are  described  below.  As  previously  noted,  the  Script  Model  was 
based  solely  on  the  COASTS  Tsunami  scenario  script  and  contains  no  variation,  meaning 
all  process  times  are  constant. 

a.  Entities 

The  description  and  role  of  each  equipment  entity  have  been  previously 
explained  in  Chapter  II.  Additional  entities,  denoted  PTP,  represent  communications 
between  other  entities.  Table  2  builds  on  the  existing  entity  information  by  showing  what 
resources  are  required  for  each  equipment  entity  to  carry  out  any  process  activities.  The 
resources  are  assigned  a  representative  letter  in  Table  3  that  is  referred  to  in  Table  4. 
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Entity 

Associated  Resource 

1 

AU-23 

(a)  Air  Crew;  (b)  Pilot 

2 

PCF 

(c)  PCF  Crew 

3 

Mini  Unmanned  Aerial  Vehicle 

(d)  MUAV  Pilot 

D 

FT? 

5 

MECP 

(e)  MECP  Crew;  (f)  MECP  Security  Team 

6 

JOCC 

(g)  JOCC  Team 

Table  2.  Entity  information  for  script  model 


b.  Processes 

For  processes,  all  Type  were  standard,  all  Actions  were  seize-delay- 
release,  all  Priority  were  the  same  (medium  2),  Allocation  was  set  to  value  added  for 
each,  and  all  Units  are  in  minutes.  The  table  below  denotes  the  constant  process  delay 
times  and  the  resources  required  for  each  process. 
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a=Air  Crew  b=Pilot  c=PCF  Crew  d=MUAV  Pilot  e=MECP  Crew  f=MECP  Security  Team 

g=JOCC  Team 

Process 

Minutes 

1 

PREP  AU-23 

a,b 

62 

2 

PREP  JOCC 

g 

60 

3 

PREP  PCF 

c 

60 

a 

PREP  MECP 

e,f 

63 

5 

PREP  MUAV 

d 

139 

6 

AU-23  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

b 

8 

7 

PCF  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

c 

10 

8 

LAUNCH  MECP  AND  BEGIN  TRANSIT  TO  DISASTER 

AREA 

e,f 

17 

9 

MUAV  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

d 

15 

10 

AU-23  SURVEYS  DISASTER  AREA  AND  SENDS 
DATA  TO  JOCC 

a 

5 

11 

PCF  SURVEYS  DISASTER  AREA  AND  SENDS  DATA 
TO  JOCC 

c 

5 

12 

JOCC  PROCESSES  DATA  FROM  AU-23  AND  PCF, 
SENDS  ROUTE  DATA  TO  MECP 

g 

5 

13 

MECP  RECEIVES  ROUTE  DATA  FROM  JOCC 

5 

14 

MECP  TRANSITS  TO  DISASTER  AREA 

e,f 

55 

15 

MECP  SETS  UP,  SURVEYS,  AND  SENDS  DATA  TO 

JOCC 

e,f 

20 

16 

MUAV  SURVEYS  DISASTER  AREA  AND  SENDS 
DATA  TO  JOCC 

a. 

5 

17 

JOCC  PROCESSES  DATA  FROM  MECP  AND  MUAV, 
SENDS  DAMAGE  ASSESSMENT  TO  NGO’S 

g 

5 

Table  3.  Script  Model  processes  information 


D.  BASELINE  MODEL 


The  Baseline  Model  was  structured  on  the  COASTS  Tsunami  scenario  script  but 
has  been  injected  with  realistic  variability  by  altering  all  process  delay  times  to  a 
probabilistic  delay  using  a  Triangular  distribution.  Since  there  was  no  real  data 
available,  it  is  not  known  what  probability  distribution  and  distribution  parameters  were 
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most  accurate.  Therefore,  using  one  of  three  distributions  ( Exponential  Triangular,  and 
Uniform)  recommended  in  the  Arena  book,  the  Triangular  distribution  was  chosen  since 
it  is  the  best  represents  the  distribution  of  process  times  for  this  particular  project  (Kelton 
pg.  183-185).  This  distribution  calls  for  Minimum ,  Most  Likely ,  and  Maximum  time 
parameters.  All  time  parameters  for  the  Baseline  Model  processes  delays  have  been 
determined  by  the  following  methods: 

•  Information  and  experiences  gained  from  being  present  at  the  live 
COASTS  experiment 

•  Knowledge  gleaned  from  interacting  with  the  equipment  operators 

•  Answers  provided  by  experiment  attendees  on  questionnaire  (Appendix  B) 

•  Ability  to  make  inferences  after  19.5  years  in  service 

The  following  table  relates  to  the  Baseline  Model  and  only  provides  details  about 
the  processes  and  their  changes  as  all  other  model  information  is  the  same  as  the  Script 
Model.  A  full  view  of  the  Baseline  Model  as  it  appears  in  Arena  can  be  seen  in 
Appendix  D. 
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a=Air  Crew  b=Pilot  c=PCF  Crew  d=MUAV  Pilot  e=MECP  Crew  f=MECP  Security  Team 

g=JOCC  Team 

Process 

Minutes 

1 

PREP  AU-23 

a,b 

30,60,90 

2 

PREP  JOCC 

g 

30,90,180 

3 

PREP  PCF 

c 

30,60,120 

a 

PREP  MECP 

e,f 

30,90,180 

5 

PREP  MUAV 

d 

10,60,90 

6 

AU-23  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

b 

10,30,60 

7 

PCF  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

c 

20,60,120 

8 

LAUNCH  MECP  AND  BEGIN  TRANSIT  TO  DISASTER 

AREA 

10,30,60 

9 

MUAV  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

d 

15,30,45 

10 

AU-23  SURVEYS  DISASTER  AREA  AND  SENDS 
DATA  TO  JOCC 

a 

10,15,30 

11 

PCF  SURVEYS  DISASTER  AREA  AND  SENDS  DATA 
TO  JOCC 

c 

15,30,60 

12 

JOCC  PROCESSES  DATA  FROM  AU-23  AND  PCF, 
SENDS  ROUTE  DATA  TO  MECP 

g 

5,30,60 

13 

MECP  RECEIVES  ROUTE  DATA  FROM  JOCC 

e,f 

1,5,15 

14 

MECP  TRANSITS  TO  DISASTER  AREA 

e,f 

30,60,120 

15 

MECP  SETS  UP,  SURVEYS,  AND  SENDS  DATA  TO 

JOCC 

e,f 

30,60,180 

16 

MUAV  SURVEYS  DISASTER  AREA  AND  SENDS 
DATA  TO  JOCC 

o. 

5,10,30 

17 

JOCC  PROCESSES  DATA  FROM  MECP  AND  MUAV, 
SENDS  DAMAGE  ASSESSMENT  TO  NGO’S 

g 

20,40,90 

Table  4.  Baseline  Model  processes  information 


E.  SCRIPT  AND  BASELINE  MODEL  RESULTS  AND  ANALYSIS 


The  Script  Model  results  did  not  deviate  from  the  COASTS  Experiment  scenario 
that  was  executed.  This  model  was  that  way  to  provide  a  benchmark  that  could  be  built 
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upon,  and  also  so  that  enhancements  could  be  added.  The  results  generated  by  the  Script 
Model  (Table  5)  follow  the  script  event  flow  perfectly  showing  that  it  took  ultimately  165 
minutes  for  the  JOCC  to  send  the  damage  assessment  to  the  NGO's. 

Table  5  highlights  the  difference  in  times  needed  to  send  data  from  one  entity  to 
the  next  starting  at  simulation  time  zero  and  ending  at  the  time  the  communications 
happened.  These  metrics  are  our  best  gauge  of  how  the  system  functions  and  can  quickly 
reveal  possible  problems.  The  Baseline  Model  has  been  replicated  200  times.  This 
number  of  replications  was  chosen  because  it  is  a  large  enough  sample  to  produce 
acceptable  Average  times  based  on  the  Confidence  Interval  (value  range  above  and  below 
the  average  based  on  the  half  width)  also  displayed  in  Table  5.  All  Times  in  Table  5  have 
been  rounded  to  the  nearest  minute. 


**A11  Time  is  in 

Script  Model 

1  Baseline  Model 

Minutes 

(Constant 

Delay) 

1  (Triangular  Delay,  200  Replications) 

Time  Until 

Data  Sent 

Average  Time 
Until  Data  Sent 

Confidence 

Interval 

Min 

Max 

AU23  to  JOCC 

75 

in 

[109,  114] 

71 

154 

PCF  to  JOCC 

75 

173 

[169,  177] 

97 

238 

JOCC  to  MECP 

80 

205 

[201,210] 

136 

287 

MUAV  to  JOCC 

160 

327 

[322,331] 

225 

422 

MECP  to  JOCC 

160 

372 

[365,  378] 

233 

497 

JOCC  to  NGO 

165 

423 

[416,  430] 

293 

558 

Table  5.  Comparison  of  Script  and  Baseline  Model  metrics 


The  value  of  the  Baseline  Model  is  that  it  provides  a  more  realistic  picture  of  the 
system  by  using  a  range  of  possible  process  times  as  opposed  to  assigning  a  specific 
value  to  the  processes  or  shortening  them  for  the  sake  of  the  experiment  as  with  the  Script 
Model.  Therefore  the  Baseline  Model  is  the  starting  point  for  all  experimental  models 
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described  in  Chapter  IV.  As  expected,  the  Baseline  Model,  having  been  injected  with 
more  realistic  process  times  and  process  time  variability,  shows  that  it  takes 
approximately  128  minutes  longer  to  get  the  damage  assessment  from  the  JOCC  to  the 
NGO’s  best  case,  423  minutes  longer  worst  case,  and  258  minutes  longer  on  average.  In 
essence,  based  on  the  simulation  results,  it  takes,  on  average,  seven  hours  for  the  damage 
assessment  system  to  realistically  run  its  course  given  the  parameters  listed  in  Table  4. 
As  previously  stated  in  this  chapter,  due  to  time  and  resource  constraints,  some  of  the 
script  activities  were  not  fully  acted  out  during  the  COASTS  experiment  which  would 
account  for  the  large  time  differences  in  Table  5. 
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IV.  EXPERIMENTAL  MODELS 


Once  the  Baseline  Model  has  been  established,  the  model  can  be  further  expanded 
to  include  the  possibilities  of  other  random  events  such  as  equipment  failures  and  bad 
weather  delays.  Chapter  IV  provides  details  on  about  the  creation  of  three  experimental 
models  that  were  designed  using  the  Baseline  Model  as  the  starting  point. 

A.  EQUIPMENT  FAILURE  MODEL 

Equipment  failures  are  inevitable  and  inherent  part  of  any  system  and  must  be 
planned  for.  Failures  of  this  nature  are  generally  random  and  can  be  reduced  by 
aggressive  preparation,  planning  and  preventative  maintenance.  However,  the  possibility 
of  equipment  failures  can  never  be  eliminated.  That  said,  in  order  to  test  this  system 
under  more  realistic  conditions,  this  model  enhancement  must  be  included.  The  model 
demonstrates  how  equipment  failures  that  have  been  assigned  probabilities  and  triangular 
delay  times  can  impact  the  amount  of  time  is  takes  for  reports  to  be  sent  across  all  paths. 

Using  the  Baseline  Model  as  a  start  point,  temporary  failure  delays  were  built  into 
the  model  by  first  creating  a  Failure  Table  within  the  modeling  software  using  the  data  in 
Table  6.  Specific  data  for  failure  likelihoods  were  not  available  due  to  the  fact  the 
COASTS  experiment  summary  did  not  incorporate  failure  data;  therefore.  Probabilities 
and  Down  Times  in  Table  6  are  reasonable  guesses. 

The  equipment  and  problems  listed  in  Table  6  were  reasonable  estimations  based 
on  a  combination  of  factors  such  as  age  of  equipment,  projected  reliability  of  power  grid 
following  a  disaster  and  most  likely  issues  based  on  equipment  type.  The  probabilities 
and  down  time  associated  with  these  problems  were  determined  much  the  same  way  and 
are  a  mix  of  reasonable  guesses  based  partially  on  real  issues  that  surfaced  during  the  dry 
runs  mentioned  at  the  end  of  Chapter  I. 
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Problem 

Probability  of  Problem 
Occurring 

Time  Down 
in  Minutes 

AU-23 

Gauge  Malfunction 

5% 

1,  15,  60 

JOCC 

Power  Outage 

1% 

1,30,  120 

MECP 

Mechanical  Problems 

5% 

5,  30,  60 

MUAV 

Battery  Not  Charged 

3% 

30,  60,  90 

PCF 

Engine  Will  Not  Start 

5% 

5,  15,  60 

Table  6.  Details  of  failures  built  into  Baseline  Model  to  create  Equipment  Failure  Model 


When  creating  the  Failure  Table ,  the  failure  Type  for  all  was  time  and  the  formula 
used  to  populate  the  Up  Time  field  was  based  on  a  discrete  probability  using  the 
expression:  DISC  (probability  of  problem,  UNIF  (0,  mimimum  system  run  time  from 
Baseline  Model),  1.0,  10000).  For  example,  the  formula  for  AU-23  Up  Time  is  DISC 
(0.05,  UNIF  (0,293),  1.0,  10000).  This  formulation  for  Up  Time  allows  the  coding  of  a 
probability  that  the  failure  will  occur  during  the  simulation  run.  To  insure  that,  if  failure 
was  supposed  to  happen  according  to  the  results  of  the  draw  from  the  discrete 
distribution,  that  the  failure  did  actually  occur,  the  longest  possible  Up  Time  for  this  case 
was  set  to  293  minutes,  which  was  determined  from  the  Base  Model  results  to  be  the 
fastest  time  that  the  simulation  could  run.  Note  however,  that  it  is  possible  for  an 
equipment  failure  to  occur  after  that  equipment  has  sent  its  required  communication  so 
the  failure  may  not  necessarily  cause  the  delay  of  other  activities.  This  was  determined  to 
be  the  most  realistic  and  effective  way  to  code  the  failures. 

The  Down  Time  field  was  populated  using  a  triangular  distribution  using  the 

numbers  presented  in  Table  6.  Once  the  failures  were  created  they  were  associated  to  the 

equipment  via  resources  needed  to  operate  the  equipment.  For  example,  the  Pilot  is  a 

resource  needed  to  operate  the  AU-23  throughout  every  process;  therefore  by  attaching 

the  failure  probability  to  the  pilot,  the  AU-23  is  by  probabilistically  failed  by  association. 

This  association  to  a  resource  other  than  the  actual  equipment  was  required  since  the 

equipment  was  modeled  as  an  entity  rather  than  a  resource.  This  strategy  required  a 
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slight  modification  to  the  Baseline  Model  when  it  came  to  the  JOCC  Power  Outage 
failure.  Since  a  power  failure  affects  all  data  transmission  to  and  from  the  JOCC,  all  data 
transmission  activities  had  to  be  isolated  in  their  own  processes  so  all  necessary  resources 
could  be  properly  required,  and  therefore  all  data  transmissions  properly  affected  by  a 
failure.  Therefore  all  processes  that  combined  surveying  and  data  transmission  had  to  be 
split.  This  allowed  for  the  JOCC  Team  resource,  with  the  power  failure  attached  to  it,  to 
be  added  to  all  data  transmission  processes,  regardless  of  which  piece  of  equipment  was 
communicating  with  the  JOCC.  The  newly  added  Send  Data  processes  for  each  piece  of 
equipment  were  given  a  constant  time  of  1  minute.  Consequently,  all  process  times 
associated  with  the  Survey  process  were  reduced  by  1  minute  as  to  not  skew  the  total  time 
required  for  the  Survey  and  Send  Data  processes  together.  By  doing  this,  the  model 
simulated  the  failure  of  all  data  transmissions,  regardless  of  which  equipment  failed, 
injecting  additional  realism  into  the  model. 

B.  WEATHER  DELAY  MODEL 

As  with  equipment  failures,  bad  weather  is  also  something  relief  workers  have  to 
consider.  For  the  purposes  of  this  project,  bad  weather  is  defined  as  heavy  rain,  flooding, 
high  seas,  or  high  winds,  or  something  of  the  like  which  exists  to  some  degree  during  the 
disaster  response  window.  The  residual  effects  of  weather  related  disasters  such  as 
hurricanes  and  typhoons  are  likely  factors  that  will  impact  the  response  and  must  be 
planned  for.  The  Weather  Delay  Model  is  designed  to  simulate  likely  delays  due  to  bad 
weather. 

The  Weather  Delay  model  used  the  Baseline  Model  as  a  starting  point  just  as  the 
Equipment  Failure  Model  did.  Temporary  delays  were  built  into  the  model  by  creating  a 
Weather  entity.  The  Weather  entity  was  then  sent  into  a  decision  module  that  was  given 
the  probability  of  10%,  Every  time  this  decision  is  true,  the  Weather  entity  proceeds  to 
an  assign  module  where  it  changes  the  value  of  a  variable  named  Bad  Weather  from  the 
initial  value  of  zero  to  a  new  value  of  1  (Figure  7). 
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Figure  6.  Snapshot  of  Arena  10.0  Module  Additions  Needed  to  Complete  the 

Weather  Delay  Model 

The  variable  Bad  Weather  has  been  linked  to  each  process  that  would  be  delayed 
(Table  8)  using  a  mathematical  expression  inserted  in  the  Delay  Type  field  of  each 
affected  process  module.  The  expression,  TRIA(  ,  ,  )  +  Bad  Weather  *  TRIA( ,  ,  ),  is 
designed  to  use  the  original  process  times  (Table  4)  in  the  first  set  of  parenthesis  and  the 
estimated  additional  delay  times  due  to  bad  weather  (Table  8)  in  the  second  set  of 
parenthesis.  When  the  Bad  Weather  variable  retains  its  default  value  of  zero,  the 
additional  process  delay  time  is  cancelled  out  so  only  the  original  process  delay  is 
experienced.  Just  like  the  Equipment  Failure  Model,  specific  data  for  delay  likelihoods 
were  not  available  due  to  the  fact  the  COASTS  experiment  summary  did  not  incorporate 
weather  delay  data;  therefore,  the  processes  that  would  be  delayed  and  the  additional 
weather  delay  times  in  Table  7  are  reasonable  guesses  based  on  a  mixture  of  reasonable 
guesses  and  real  issues  that  surfaced  during  the  dry  runs  mentioned  at  the  end  of  Chapter 
I. 


30 


Process  Being  Delay  ed 

PREP  JOCC 

5,  30,  90 

PREP  PCF 

10,  30,  60 

AU-23  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

20,  45,  90 

PCF  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

20,  40,  60 

LAUNCH  MECP  AND  BEGIN  TRANSIT  TO  DISASTER  AREA 

5,  30,  90 

MUAV  LAUNCH  AND  TRANSIT  TO  DISASTER  AREA 

10,  20,  45 

AU-23  SURVEYS  DISASTER  AREA  AND  SENDS  DATA  TO  JOCC 

5,  10,  15 

PCF  SURVEYS  DISASTER  AREA  AND  SENDS  DATA  TO  JOCC 

10,  30,  60 

MECP  TRANSITS  TO  DISASTER  AREA 

10,  20,  60 

MECP  SETS  UP,  SURVEYS,  AND  SENDS  DATA  TO  JOCC 

15,45,  120 

MUAV  SURVEYS  DISASTER  AREA  AND  SENDS  DATA  TO  JOCC 

1,5,10 

Table  7.  Processes  affected  by  bad  weather  with  associated  delay  times 


C.  COMBINATION  MODEL 

The  Combination  Model  combines  the  two  previous  experiments  and  is  designed 
to  simulate  likely  delays  due  to  equipment  failures  and  bad  weather.  It  is  the  Baseline 
Model  with  all  of  the  equipment  failures  and  weather  delays  of  the  previous  two  models 
added  in.  Since  the  Equipment  Failure  Model  split  the  four  Survey  and  Send  Data 
processes  into  eight  processes,  the  Bad  Weather  Delay  that  was  originally  associated  with 
those  processes  was  applied  to  the  Survey  portion  and  not  the  Send  Data.  The  results  and 
analysis  of  all  models  are  presented  in  Chapter  V. 


31 


THIS  PAGE  INTENTIONALLY  LEFT  BLANK 


32 


V.  RESULTS  AND  ANALYSIS 


The  following  paragraphs  and  tables  provide  summarized  results  and  analysis  of 
all  models  with  variability.  More  specifically,  the  goal  of  this  chapter  is  to  show  the 
averages  and  the  ranges  and  variation  when  comparing  the  three  experimental  models  to 
the  Baseline  Model,  emphasizing  the  differences  between  the  Average,  Minimum ,  and 
Maximum  time  needed  to  send  data.  As  previously  stated,  each  model  has  been 
replicated  200  times. 

A.  RESULTS  AND  ANALYSIS  OF  AVERAGE  TIMES 

Table  8  shows  Average  Time  Until  Data  Sent.  To  understand  the  results  in  Tables 
8,  9,  and  10,  a  rough  critical  path  analysis  was  performed  based  on  most  likely  process 
delay  times.  The  critical  path  for  this  system,  defined  as  path  that  goes  from  start  to 
completion  which  takes  the  longest,  is:  Process  C-G-K-L-M-N-O-Q.  The  critical 
path  takes  a  total  of  335  minutes  using  Most  Likely  times  from  Table  4  and  is  linked  at 
some  point  to  all  other  paths.  All  other  paths  have  significantly  lower  Most  Likely  times, 
and  therefore  have  quite  a  bit  of  slack. 

The  Equipment  Failure  Model  average  times  reflected  in  Table  8  do  not  vary 

much  from  the  Baseline  Model  averages.  There  is  one  significant  jump  in  the  AU23  to 

JOCC  path  of  10  minutes  but  the  remaining  communications  only  took  one  to  two 

minutes  longer.  When  considering  the  confidence  intervals  in  Table  9,  this  difference  is 

not  significant.  Looking  back  at  Table  6  (details  of  Equipment  Failure  Model)  it  would 

seem  as  though  there  would  be  a  larger  time  difference  in  the  other  five  paths.  However, 

this  small  change  is  due  to  a  complex  set  of  factors  that  includes  number  of  replications, 

probabilities  of  equipment  failure  delays,  slack  time  in  others  paths  when  compared  to  the 

critical  path,  and  the  larger  difference  between  the  Most  Likely  and  Maximum  times  in 

the  Triangular  delay.  For  instance,  when  looking  at  the  AU-23  to  JOCC  path  which  had 

the  largest  increase  in  time,  there  are  three  processes  in  that  path  that  could  experience  an 

equipment  failure.  Each  of  those  occurrences  has  a  5%  probability.  This  specific  path  is 

not  the  critical  path;  it  does  not  take  nearly  as  long  as  the  critical  path,  and  has  relatively 
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low  delay  times.  Therefore,  though  changes  occur  in  leaps  on  this  path  they  do  not 
necessarily  affect  the  other  five  paths  due  to  lack  of  influence  on  one  another  or  due  to 
the  path  being  connected  to  takes  considerably  longer  anyway  and  is  not  impacted  by 
changes  on  the  shorter  path. 


Average  Time  Until  Data  Sent  For  All  Models  (200  Reps) 

Script 

Baseline 

Eqpmt  Failure 

Bad  Weather 

Combination 

AU23  to  JOCC 

75 

1 1 1 

121 

116 

127 

PCF  to  JOCC 

75 

173 

174 

180 

183 

JOCC  to  MECP 

80 

205 

205 

213 

216 

MUAV  to  JOCC 

160 

327 

329 

342 

346 

MECP  to  JOCC 

160 

372 

374 

392 

390 

JOCC  to  NGO 

165 

423 

424 

444 

443 

Table  8.  Comparison  of  average  times  until  data  sent  for  all  models 


95%  Confidence  Intervals  (based  on  200  Reps) 

Baseline 

Eqpmt  Failure 

Bad  Weather 

Combination 

AU23  to  JOCC 

[109,  1141 

[118,  124] 

[113,  120] 

[122,  130] 

PCF  to  JOCC 

[169,  177] 

[170,  178] 

[175,  184] 

[178,  189] 

JOCC  to  MECP 

[201,210] 

[202,  209] 

[209,218] 

[209,  220] 

MUAV  to  JOCC 

[322, 331] 

[324,  334] 

[335,  349] 

[338,  354] 

MECP  to  JOCC 

[365,  378] 

[368,381] 

[383,401] 

[381,399] 

JOCC  to  NGO 

[416,  430] 

[418,431] 

[435,  453] 

[433,  453] 

Table  9.  95%  Confidence  Intervals 
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The  Weather  Delay  Model  on  the  other  hand  varied  quite  distinctly  from  the 
Baseline  and  Equipment  Failure  Models  with  significant  increases  in  five  out  of  six 
average  time  metrics.  These  increases  can  be  attributed  to  the  same  complex 
combination  of  factors  mentioned  above  but  it  is  the  details  of  these  factors  that  help 
explain  the  larger  increases.  The  greatest  impact  on  average  times  is  the  fact  that  the 
Weather  Delay  Model  carries  a  higher  probability  of  10%  as  opposed  to  the  Equipment 
Delay  Models  range  of  1%  to  5%.  Additionally,  the  Weather  Delay  Model  also  contains 
a  wider  variation  of  delay  times  when  compared  to  the  Equipment  Failure  Model,  which 
could  account  for  the  AU-23  to  JOCC  average  time  being  smaller  when  compared  to  the 
Equipment  Failure  Model. 

Finally,  the  Combination  Model  was  expected  to  show  an  increase  in  average 
times  beyond  that  of  the  Equipment  Failure  and  Weather  Delay  Models,  especially  in  the 
JOCC  to  NGO  path  (which  is  on  the  critical  path).  The  expectation  to  see  a  significant 
increase  was  due  to  the  fact  that  the  delays  would  build  on  each  other  in  turn  resulting  in 
higher  averages  when  compared  to  all  other  models.  This  did  occur  in  four  out  of  six 
communication  paths  and  with  reasonable  accuracy,  as  you  would  expect  the 
Combination  Model  average  times  to  roughly  equal  the  difference  in  the  Equipment 
Delay  Model  and  Baseline  Average  Times  added  to  the  Weather  Delay  Model  average 
times.  Of  the  two  paths  that  did  not  increase,  there  was  one  path  that  in  particular  that 
was  extremely  difficult  to  comprehend,  the  JOCC  to  NGO  path  which  apparently 
decreased  by  one  minute.  Due  to  this  unexpected  result,  the  experimental  models  were 
re-examined  to  insure  there  were  no  model  errors,  and  re-run  for  1,000  replications  but 
the  results  showed  little  variation  with  the  exception  of  a  reduction  in  half  width.  Despite 
the  fact  the  half-widths  were  reduced,  the  confidence  intervals  continued  to  overlap  and 
more  closely  than  those  shown  in  Table  9  leading  to  the  conclusion  are  not  significantly 
different.  It  is  reasonable  to  conclude  that  running  the  models  for  5,  10,  or  15  thousand 
replications  would  further  hone  in  on  the  true  average  times  but  for  a  system  that  takes 
400+  minutes  to  complete  the  mission,  determining  if  one  model  actually  takes  half  a 
minute  more  than  another  on  average  is  not  significant  enough  to  warrant  this  more 
extensive  analysis.  However,  it  is  somewhat  surprising  that  the  addition  of  equipment 
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delays  (the  only  difference  between  the  Baseline  Model  and  the  Equipment  Failure 
Model,  as  well  as  between  the  Weather  Model  and  the  Combined  Model)  is  not  slightly 
more  noticeable. 

B.  RESULTS  AND  ANALYSIS  OF  MIN  AND  MAX  TIMES 

Greater  variation  is  expected  when  comparing  the  min  and  max  metrics  due  to  the 
likelihood  of  outliers.  Tables  10  and  1 1  show  minimum  and  maximum  time  results  for 
all  models  respectively  based  on  200  simulation  replications.  These  metrics  would  likely 
act  as  a  guide  for  relief  workers  showing  them  the  earliest  and  latest  likely  times  they 
could  plan  to  execute  follow  on  activities.  Just  like  in  the  average  times  comparison 
table,  the  resulting  times  in  these  tables  reflect  more  of  the  same  phenomenon  with  regard 
to  unexpected  results. 


Minimum  Time  Until  Data  Sent  For  All  Models  (min) 

Script 

Baseline 

Eqpmt  Failure 

Bad  Weather 

Combination 

AU23  to  JOCC 

75 

71 

81 

69 

79 

PCF  to  JOCC 

75 

97 

107 

112 

114 

JOCC  to  MECP 

80 

136 

143 

144 

139 

MUAV  to  JOCC 

160 

225 

251 

249 

255 

MECP  to  JOCC 

160 

233 

270 

274 

277 

JOCC  to  NGO 

165 

293 

312 

337 

315 

Table  10.  Comparison  of  minimum  times  until  data  sent  for  all  models 
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Maximum  Time  Until  Data  Sent  For  All  Models  (min) 

Script 

Baseline 

Eqpmt  Failure 

Bad  Weather 

Combination 

AU23  to  JOCC 

75 

154 

173 

200 

233 

PCF  to  JOCC 

75 

238 

275 

299 

299 

JOCC  to  MECP 

80 

287 

312 

346 

331 

MUAV  to  JOCC 

160 

422 

472 

558 

552 

MECP  to  JOCC 

160 

497 

508 

607 

626 

JOCC  to  NGO 

165 

558 

554 

670 

668 

Table  1 1.  Comparison  of  maximum  times  until  data  sent  for  all  models 


When  comparing  the  Equipment  Failure  Model  to  the  Baseline  Model  for  both 
min  and  max,  we  see  that  there  is  an  increase  in  times  across  the  board  with  the  exception 
of  the  max  time  for  the  JOCC  to  NGO  path.  This  can  only  be  explained  in  much  the 
same  way  as  the  average  time  phenomenon  for  the  same  path  above.  Since  this 
communication  is  on  the  critical  path  and  there  is  considerable  slack  on  those  paths 
around  it,  fluctuations  in  those  paths  do  not  affect  JOCC  to  NGO  path,  in  this  case 
causing  it  to  actually  decrease  by  2  minute.  That  said,  all  previously  mentioned  factors 
such  as  probabilities  of  failure  and  delay  combined  with  variable  delay  times  cannot  be 
overlooked  and  surely  contribute  to  this  unexpected  result. 

The  remaining  models  show  much  of  the  same  unexpected  pattern  when 
compared  to  the  model  that  precedes  it.  Both  min  and  max  times  would  be  expected  to 
increase  when  going  from  the  Baseline  Model  to  the  Combination  Model  respectively  but 
as  shown  Tables  10  and  1 1  are  littered  with  data  points  which  prove  otherwise. 
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VI.  CONCLUSIONS  AND  RECOMMENDATIONS 


As  previously  stated,  the  COASTS  Experiment  proved  that  the  damage 
assessment  system  tested  in  this  project  works  and  is  a  realistic  option  when  looking  for  a 
system  that  can  provide  support  in  a  disaster  situation.  This  project  expands  on  their 
experiment  by  using  discrete  event  simulation  to  determine  realistic  times  for  setting  up 
and  employing  this  system.  The  following  discussion  provides  a  wrap  up  of  the  project 
to  include  conclusions  based  on  model  results  and  recommendations  on  project 
improvement  and  continued  research. 

This  project  used  the  COASTS  Experiment  as  a  starting  point  for  a  more  detailed 
and  realistic  study  of  a  specific  damage  assessment  system.  A  highlight  of  this  project  is 
the  difference  between  the  Script  Model  when  compared  to  the  other  four  models.  The 
considerable  difference  in  average  times  supports  the  points  made  in  Chapter  I  regarding 
live  experiment  limitations  and  the  value  of  DES  modeling. 

As  with  any  type  of  research,  there  are  a  number  of  issues  that  surfaced 
throughout  the  study,  which  provided  insight  for  areas  of  improvement.  The  most 
significant  recommendation  towards  the  improvement  of  this  project  would  be  the 
collection  of  real  data  points  for  use  in  the  models.  Despite  the  fact  that  the  COASTS 
Experiment  was  based  on  a  script  and  that  data  points  used  in  the  simulation  model  were 
relatively  good  estimates  based  on  real  experiences,  the  documenting  of  real  prep  times, 
set  up  times,  flight  times,  failure  times,  etc.,  would  provided  an  even  more  realistic 
foundation  for  these  DES  models.  That  said,  recording  a  comprehensive  list  of  data 
points  would  have  not  been  reasonable  due  to  the  time  compression  and  constraints  of  the 
COASTS  Experiment,  but  consideration  should  be  given  to  conducting  future  live 
experiments  that  involve  all  activities  being  acted  out  from  beginning  to  end.  In  addition 
to  data  points  associated  with  time,  recording  the  effect  that  severe  weather  has  on  the 
equipment  being  tested  is  recommended. 
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With  regard  to  future  research  in  this  area,  I  would  recommend  the  continued 
study  of  damage  assessment  systems  similar  to  or  with  the  same  purpose  as  the  one  in 
this  project.  In  my  opinion,  although  there  has  been  a  tremendous  amount  of  research 
conducted  in  each  subsystem  to  include  HFN’s  and  MUAV’s  seemingly,  little  attention 
has  been  given  to  putting  these  subsystems  together  in  the  form  of  a  multi-pronged 
assessment  system  capable  of  providing  so  much  critical  information  and  communication 
abilities  for  so  many  disaster  response  participants. 
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APPENDIX  A  (SCENARIO  SCRIPT) 


Humanitarian  Assistance  Phase-1  Scenario  Script 

00:00  Phase  1  COMEX.  One  hour  after  the  tsunami  has  hit  the  coastal 
region.  The  CTF-COASTS  liaison  to  COASTS  team  requests  assistance  to 
survey  the  scope  of  the  disaster  and  initiate  search,  rescue,  and  recovery 
efforts.  After  an  additional  hour  of  coordination  and  crisis  planning, 
COASTS  has  determined  how  best  to  support  this  request  and  coordinate  the 
support  with  the  host-nation.  Time  elapsed  since  Tsunami  +02:00. 

00:01  JOCC  Directs  AU-23  Mosquito  to  be  launched  from  Wing-5  and 
dispatched  to  disaster  region. 

00:01  JOCC  Director  (Ch-1):  “Airboss,  JOCC,  launch  alert  AU-23  to  disaster 
region.” 

Airboss  (Ch-1):  “Roger,  launch  alert  AU-23” 

00:01+30  Airboss  (VHF):  “Mosquito  01,  Airboss,  launch  and  depart  to  disaster  area, 
report  on  ground  routes  and  extent  of  damage” 

Mosquito  01  (VHF):  “Roger,  launch  and  depart” 

00:02  Mosquito  01  (VHF-tower):  “Ao  Manao  Tower,  Mosquito  01  ready  for 
takeoff,  turnout  to  northwest  and  departure  to  south.” 

Tower  (VHF):  Provides  necessary  clearance. 

00:02  JOCC  Directs  Mobile  Emergency  Command  Post  (MECP)  Team 
to  depart  Wing-5  for  disaster  zone. 

00:02  JOCC  Director  (Ch-1):  “MECP,  JOCC,  depart  for  disaster  zone” 

MECP  (Ch-1):  “Roger,  departing” 

00:03  JOCC  Director  (VOIP):  “PCF,  JOCC,  transit  to  offshore  of  disaster  region” 
PCF  (VOIP):  “Roger,  departing” 

00:15  AU-23  arrives  over  disaster  area,  video  provided  to  COASTS 

JOCC  and  to  remote  sites  via  COASTS  network.  PCF  arrives  in  disaster 
area. 

00:15  Mosquito  01  (VHF):  “JOCC,  Mosquito  01,  I  am  over  disaster  zone  now. 

Coastal  zone  has  sustained  significant  damage.  Buildings  and  coastal  road 
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appear  damaged.  Large  number  of  bodies  near  shoreline  or  in  water.  Will 
transmit  video.” 

JOCC  Director  (VHF):  “Mosquito  01,  JOCC,  understand  significant 
damage  and  loss  of  life,  waiting  on  video” 

00:15+30  PCF  (VOIP):  “JOCC,  PCF,  I  am  offshore  from  disaster  zone.  I  confirm 
report,  significant  damage  and  bodies  awash  in  water.” 

JOCC  Director  (VOIP):  “PCF,  JOCC,  thank  you  for  confirmation” 

00:20  Timeline  compression.  60  minutes  simulated  elapsed.  After  short 
survey  of  disaster  area,  routes  are  determined  into  the  area  for  disaster  relief 
teams.  JOCC  relays  this  information  to  the  inbound  MECP  Team.  AU-23 
uses  loiter  capability  to  remain  over  area  and  provide  continued  SA  and 
support.  MECP  arrives  in  disaster  area. 

00:20  MECP  (SATCOM):  “JOCC,  MECP,  we  have  arrived  in  disaster  zone, 
initiating  setup,  standby  for  video,  TwiddleNet,  and  reporting” 

JOCC  Director  (SATCOM):  “Roger  MECP,  JOCC  standing  by” 

JOCC  Director  (Ch-1):  “Lauch  UAV” 

UAV  Site  (Ch-1):  “Roger  JOCC,  launching  UAV” 

00:40  MECP  set  up  complete  (including  TwiddleNet)  and  initial  reports 
data-linked  back  via  satellite  to  COASTS  JOCC.  Mini-UAV  supports 
MECP,  reporting  on  damage  to  surrounding  area  through  aerial  surveillance. 

00:40  MECP  (SATCOM):  “JOCC,  MECP,  you  should  be  receiving  video  and 
TwiddleNet.  Coastal  region  has  suffered  significant  loss  of  life  and  damage, 
this  is  a  major  disaster  zone.  Inland  road  structure  is  intact,  but  refugees  are 
flooding  the  network.  Local  communications  are  down.  Medical  assistance 
and  housing  needs  have  priority.” 

JOCC  Director  (SATCOM):  “MECP,  JOCC,  Roger,  will  pass  your 
information  to  higher,  continue  observation  and  reporting” 

00:45  Reports  on  damage/scope  of  disaster  relayed  from  COASTS 
JOCC  to  host-nation  Command  Center  and  local  NGO  headquarters  in 
capital. 

00:45  JOCC  Director  (Phone):  Makes  contact  with  host-nation  command  center(s) 
and  local  NGO  headquarters  to  confirm  receipt  of  information 

00:50  Phase  1  FINEX:  Mini-UAV  recovers.  MECP  Return  to  base. 
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APPENDIX  B  (COASTS  EXPERIMENT  SUMMARY) 


Key  Excerpts  Concerning  Daytime  Final  Experiment  Taken  from 

COASTS  27  May  2008  Daily  Sitrep 

PROGRAM  MANAGER’S  SUMMARY: 

The  Cooperative  Operations  and  Applied  Science  &  Technology  Studies  (COASTS) 
International  Field  Experimentation  Team  conducted  its  final  day  of  operations  at  Wing-5  on 
the  Royal  Thai  Air  Force  (RTAF)  Base  in  Prachuap  Khiri  Khan  on  27  May  2008.  Two 
scenario  runs  were  successfully  conducted,  one  during  the  afternoon  and  one  after  dark. 
COASTS  participants  and  observers  numbered  over  one  hundred  (100)  people  representing 
the  following  organizations: 

•  Royal  Thai  Defense  Science  &  Technology  Office 

•  Royal  Thai  Air  Force 

•  Royal  Thai  Navy  (RTN) 

•  Royal  Thai  Navy  SEALs 

•  Royal  Thai  Naval  Research  &  Development  Office  (NRDO) 

•  Royal  Thai  Military  Research  &  Development  Center  (MRDC) 

•  RTN  Engineering  Officers  School 

•  Petroleum  Authority  of  Thailand  (PTT) 

•  Electrical  and  Electronics  Products  Testing  Center  (PTEC) 

•  Naval  Postgraduate  School  (NPS)  faculty  and  students 

•  U.S.  Special  Operations  Command  (USSOCOM) 

•  Defense  Information  Systems  Agency  (DISA) 

•  Office  of  Naval  Research  (ONR)  reservists 

•  U.S.  Army  Training  and  Doctrine  Command  (TRADOC)  Analysis 
Center/Engineering  Research  and  Development  Center  (TRAC-ERDC) 

•  U.S.  Air  Force  37th  Security  Forces  Squadron 

•  Naval  Surface  Warfare  Center-Panama  City  Division  (NSWC-PCD) 

•  U.S.  Marine  Forces  Pacific  (MARFORPAC) 

•  MARFORPAC  Experimentation  Center  (MEC) 

•  III  Marine  Expeditionary  Force  (MEF) 

•  Joint  U.S.  Military  Advisors  Group  Thailand  (JUSMAGTHAI) 

•  Embassy  of  Greece 

•  Hellenic  Air  Force 

•  Turkish  Air  Force 

•  Numerous  industry  and  commercial  partners 

1.  MAJOR  ACCOMPLISHMENTS 

•  Successfully  ran  all  Scenario  Phases  (1,  2 A,  2B,  3)  during  the  day  time  using  a 
compressed  timeline. 

•  Successfully  ran  Scenario  Phases  2A  and  2B  during  the  night. 
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•  Hosted  several  arriving  VIPs  including  Lieutenant  General  Apichart  (Director 
General  DSTO),  Major  General  Thitinant  (Deputy  Director  General  DSTO),  Air 
Vice  Marshal  Wanchai  (Special  Projects  Officer,  DSTO),  Air  Vice  Marshal 
Thanongsak  (RTAF  Security  Force  Command),  Mr.  Constantine  Danassis 
(Deputy  Head  of  Mission,  Embassy  of  Greece)  and  Mr.  Niyazi  Evren  Akyol 
(First  Secretary,  Turkish  Embassy). 

2.  KEY  ISSUES 

•  A  power  outage  during  the  morning  knocked  the  Digital  Video  Recorder  out 
despite  being  connected  to  an  Uninterrupted  Power  Supply  (UPS). 

•  CyberBug  UAV  was  down  and  was  not  used  in  the  experiment. 

•  C-View  Periscope  is  not  functioning  properly  and  was  not  used  in  the 
scenario. 

•  One  Compact  Remote  Imaging  Sensing  System  with  Two-tt+  OutLook 
(CRISSTL)  Ball  was  broken  during  operations. 

***Skip  3,  Jump  to  4 

4.  SYSTEMS  STATUS 

4.1  Network 

a.  Achievements 

•  Network  Team  resuscitated  the  network  and  all  associated  systems  from  a 
JOCC  power  outage. 

4.1. A  TwiddleNet 

a.  Achievements 

•Phase  1:  SUCCESS 

o  Backhaul  link:  Good 

o  Humanitarian  Assistance  site  setup:  SUCCESS 

■  Setup  complete  in  less  time  allotted  in  scenario  script. 

•  Video  /  picture  with  data  was  received  at  JOCC  . 

o  Multithreading:  SUCCESS 

■  All  TwiddleNet  handhelds  were  able  to  retrieve  data  from 
other  handhelds. 

■  Pictures  were  displayed  on  server  laptop  for  instantaneous 
streaming. 

•  Radio  Communications:  SUCCESS 

•  Thai  counterparts  as  tsunami  survivors:  SUCCESS 

4.7.A  Unmanned  Air  Vehicles  (UAVs) 
a.  Achievements 

•  Video  successfully  transmitted  through  the  AeroVironment  (AV) 

Decoder  application  and  displayed  in  the  JOCC.  Additionally,  Axis  web 
servers  were  used  as  well  to  display  video  via  a  web  interface. 


44 


•  Conducted  two  Raven  UAV  flights  in  support  of  the  day/night  scenario. 
Conducted  one  additional  Raven  flight  after  the  night  scenario  in  order  to 
show  additional  1R  capability. 

b.  Near-Term  Plans/Events 

•  Nothing  to  report. 

c.  Comments/Issues 

•  During  the  day  scenario  a  lost  communication  issue  between  the  AU-23 
and  the  tower  caused  the  Raven  UAV  to  move  into  a  holding  pattern.  In 
addition,  a  Citation  aircraft  made  an  emergency  landing  during  the 
scenario.  These  issues  impacted  the  loiter  time  by  10  minutes  during  the 
scenario.  We  have  to  ensure  that  contingencies/emergencies  are  cover  in 
depth  prior  t  launching  in  future  field  experiments.  Specifically,  all 
players  need  to  be  aware  of  contingency  plans  including  scenario  delay, 
hold  position  and  altitude  and  recovery  plans. 
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APPENDIX  C  (EQUIPMENT  OPERATOR  SURVEY) 


Questionnaire 

Performance  Feedback  on  Specific  Surveillance  and 
Data  Collection  Platforms 


Principle  Investigator:  Captain  Richard  J.  Bridget*,  USMC,  Student,  GSBPP,  NPS 

Project  Title:  Analysis  of  Specific  Surveillance  and  Data  Collection  Platforms  Used  in 
Response  to  a  Tsunami 

Background:  In  May  of  2008,  the  NPS  based  Cooperative  Operations  and  Applied 
Science  and  Technology  Studies  (COASTS),  conducted  their  5th  and  final  exercise  of 
fiscal  year  2008  in  Ao  Manao,  Thailand.  Ao  Manao  is  located  on  the  Thai  Peninsula,  on 
the  gulf  side,  and  is  home  to  Wing  5  of  the  Royal  Thai  Air  Force  (RTAF).  All 
experiments  for  exercise  5  were  conducted  aboard  the  RTAF  base. 

Scenario  1  of  exercise  5  (listed  below)  was  an  experiment  that  tested  specific  surveillance 
and  data  collection  platforms  with  the  purpose  of  giving  the  Joint  Operations  Center 
(JOC)  an  operational  picture  of  the  affected  area.  This  operational  picture  was  then 
transmitted  to  multiple  emergency  response  and  support  agencies  throughout  the  regional 
and  international  community  allowing  for  a  more  efficient  support  effort. 

Task:  Using  the  script  below  as  an  established  guideline,  please  answer  the  questions 
that  follow  the  script  to  the  best  of  your  recollection.  The  questions  will  cover  the 
following  areas: 

•  Equipment  tested 

•  Time  with  regard  to  script 

•  Problems  encountered  with  the  performance  of  the  equipment 

•  Problems  encountered  due  to  external  factors 

•  Additional  comments 

***FEEL  FREE  TO  USE  EXCERPTS  FROM  TECHNICAL  DOCS,  IN¬ 
PROGRESS  OR  COMPLETED  THESIS,  ETC. ..ETC.. .THE  MORE 
INFORMATION  THE  BETTER! 

For  Script,  reference  Appendix  A 

QUESTIONS  BELOWI 
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QUESTIONS 

(use  as  much  space  as  required  to  answer  questions,  the  more  the  better!} 

1 .  Please  provide  in  as  much  detail  as  possible  a  description  of  the  equipment  you  tested 
and  what  its  purpose  was  in  the  scenario  1  experiment.  If  applicable,  please  include 
technical  specs,  references,  websites  and  any  other  resources  which  may  help  explain 
your  answers. 


2.  Please  provide  in  a  as  much  detail  as  possible  an  explanation  as  to  how  the  equipment 
you  tested  compared  to  the  timeline  provided  in  the  script  above,  i.e.  the  MECP  took 
much  longer  to  set  up  than  the  script  depicted  therefore  throwing  off  the  timeline, 
etc... and  here  is  why... 


3.  Please  provide  in  as  much  detail  as  possible  an  explanation  of  any  and  all 
problems/issues  you  had  with  the  equipment  you  were  testing  while  the  experiment  was 
being  conducted  to  include  problems  that  prevented  you  from  participating  in  the 
scenario  1  experiment  or  in  portions  of  it. 


4.  Please  provide  in  as  much  detail  as  possible  an  explanation  of  any  external  problems 
(not  related  to  equipment,  i.e.  weather,  clearance  from  flight  tower,  etc...)  that  prevented 
you  from  participating  in  the  scenario  1  experiment  or  in  portions  of  it. 


5.  Any  additional  comment. 
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APPENDIX  D  (ARENA  SIMULATION  MODEL:  BASELINE  ) 
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